home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / mpsnmp / mpsnmp-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  172 lines
  1. This is only a rough draft - Megan 04/09/92
  2.  
  3. Minutes of the IETF
  4. SNMP over a Multi-protocol Internet (mpsnmp) Working Group
  5. March 18 1992, San Diego CA
  6.  
  7. Mailing list
  8.     general discussion:    snmp-foo@thumper.bellcore.com
  9.     to subscribe:    snmp-foo-request@thumper.bellcore.com
  10.     archive:    thumper.bellcore.com:pub/snmp-foo/archive
  11.  
  12. Chair
  13.     Ted Brunner        tob@thumper.bellcore.com
  14.  
  15.  
  16. Meeting Notes:
  17.  
  18. The meeting started by considering the working group charter.
  19. It had not been sent out over the ietf mailing list,
  20. nor made available for anonymous ftp prior to the 
  21. first meeting of the Working Group.
  22. It was read aloud (enough paper copies were available 
  23. for about half the participants) and accepted as written.
  24.  
  25. The charter names three transport domains (OSI, Appletalk, and XNS/IPX)
  26. over which SNMP can be carried, and tasks the working group
  27. (among other things) with developing suitable encapsulation techniques.
  28. Questions were raised as to the appropriateness of considering
  29. other transport domains.  In particular running SNMP over SNA 
  30. was brought up as an interesting candidate for consideration.  
  31. The working group decided it did not have the necessary expertise 
  32. to pursue such an undertaking and it was dropped.  
  33. Running SNMP directly over Ethernet was suggested and also dropped.  
  34. There is already an RFC that deals with such a case (rfc1089).  
  35. Running SNMP over TCP was suggested.  Here the sense
  36. of the Working Group was that this was outside the scope of
  37. the charter.  The charter speaks of environments where the
  38. recommended method for exchanging SNMP messages (UDP/IP) 
  39. is not available.  It does not speak of
  40. changing the recommended method of communicating SNMP messages.
  41. The rational for choosing UDP/IP rather that TCP/IP
  42. is expressed in rfc1270.
  43.  
  44. The informational RFC (rfc1298) entitled "SNMP over IPX," was considered first.
  45. SNMP encapsulation in this case is relatively straightforward, 
  46. and all of the relevant points addressed by rfc1298 were discussed.
  47. o    It is recommended that the minimum maximum packet size supported by
  48.     the SNMP/IPX agent be raised to 546 - the limit under IPX.
  49. o    Two sockets are assigned: for get-next/sets and for traps.
  50. o    The agent address field in the trap pdu is left as 0.0.0.0
  51.     and the agent identified by the source address in the IPX header.
  52. o    The IPX addresses will be represented by an OCTET STRING.
  53. o    An OBJECT DISCRIPTOR is defined for the ipx transport domain.
  54. The working group identified a small omission.  An OBJECT IDENTIFIER for an 
  55. initial party ID was added to the rfc.
  56.  
  57. With this change, and assuming customary time for 
  58. consideration of internet-drafts and no further controversy,
  59. the working group expressed its intention to
  60. propose this rfc for promotion to "proposed standard."
  61.  
  62. A show of hands was made of companies who had implemented or 
  63. had some inclination of implementing to this standard.
  64. Present were Synoptics, Spider, MicroComm and Shiva.
  65.  
  66. The working group next considered the internet draft
  67. (draft-ietf-appleip-snmp-00.txt) entitled "SNMP over AppleTalk."
  68. SNMP encapsulation in this case was a little less straightforward.
  69. All the relevant issues raised by the draft were discussed.
  70. o    Appletalk (DDP) datagrams contain 0 to 586 octets of data.
  71. The WG recommended that the SNMP agent increase its minimum maximum
  72. packet size to 586.
  73. o    DDP Socket numbers and protocol types are assigned to SNMP
  74.     requests, responses and traps.
  75. o    In Appletalk, network elements advertize themselves using the
  76.     Name Binding Protocol (NBP) which dynamically binds names to
  77.     addresses.  A NBP type is assigned to
  78.     SNMP agents (to receive requests), and SNMP managers
  79.     (to receive traps).
  80. o    The agent address field in the trap PDU is left as 0.0.0.0.
  81.     In Appletalk the name advertized by the NBP is unique and constant,
  82.     but the address is not.  So the agent inserts its
  83.     name (object and zone) in the VarBind list of the trap PDU.
  84. o    Names are represented as OCTET STRINGs.
  85. o    There is discussion of some implications for robust service
  86.     with this use of names and the NBP to identify managers and agents.
  87.     Caching is suggested.
  88. The WG expressed possible implementation concerns at 
  89. the maximum name length of 96 bytes.
  90. The WG observed that this reliance on NBP is succeptible to denial 
  91. of service attacks, but this is not a *further* security hole to SNMP.
  92. The WG recommended that "SNMP Security Widgets" be added to this draft:
  93. Transport Domain OIDs and Default Party.
  94.  
  95. With these changes, and assuming customary time for
  96. consideration of internet-drafts and no further controversy,
  97. the working group expressed its intention to
  98. propose this internet-draft for promotion to "proposed standard."
  99.  
  100. Again a show of hands was made of companies who had implemented or
  101. had some inclination of implementing to this standard.
  102. Present were Apple, Novell and Shiva. 
  103. Mentioned but not present were Cayman, Neon, Interconn(spell? sorry.) etc.
  104.  
  105. Next the WG discussed the experimental RFC (rfc1283) "SNMP over OSI."
  106. o    Three transport mappings are included: Connectionless Transport (CLTS),
  107.     Connection Oriented Transport (COTS) over TP4 and over TP0 with X.25.
  108. o    In OSI, locally meaningful "selectors" are used where IP uses 
  109.     "well known ports." T-selectors for request/response and for trap
  110.     are specified.
  111. o    An address representation convention known as string encoding
  112.     is adopted from rfc1278.
  113. The WG agreed (with the author) to drop this convention.
  114. o    The trap pdu specifies a network address, following the 
  115.     syntax defined in the CLNP mib (rfc1238).
  116. The WG observed that this convention is not the same as that of 
  117. the previous two documents considered.  It was recommended (by the author) 
  118. that this document be changed to be consistent: the network address be
  119. left as 0.0.0.0.
  120. The WG also observed that the "SNMP Security Widgets" were not defined
  121. here.  It was recommended that they be included.
  122. The WG also observed that two transport selectors are needed,
  123. one for CLTS carried over connectionless network service,
  124. and one for CLTS carried over connection oriented network service [sic].
  125.     
  126. Further discussion evolved around the COTS, with the concern being that 
  127. the description was too vague.  It was also observed that COTS is a painful 
  128. way to support SNMP - and a full description would likewise be painful.
  129. A poll was taken of implementation experience: one implementation under BSD.
  130.  
  131. It was suggested by the WG that CLTS is the architecturally appropriate way to 
  132. support SNMP (see rfc1270), and that COTS should be dropped from the document.
  133. Other contributing factors being implementation costs of COTS compared to CLTS,
  134. and interoperability issues with COTS compared with CLTS.
  135. The suggestion was carried.
  136.  
  137. Further discussion concerned whether this WG had the authority to make this
  138. recommendation.  An informal sounding was taken of individuals
  139. present with some knowledge of other OSI efforts.  A general 
  140. agreement seemed to be that though CLTS was the better approach,
  141. but there was potential conflict with some efforts which 
  142. concentrated solely on COTS (predominately over X.25.)
  143. The Area Director for OSI Integration suggested that this WG
  144. did have the authority to set such a standard, and should
  145. seize the moment to deliver the best solution.
  146. He also offered to check with the NOOP group, which is
  147. developing OSI technology for use in the Internet,
  148. to get their reaction (expected to be positive.)
  149.  
  150. With these changes, and assuming customary time for
  151. consideration of internet-drafts and no further controversy,
  152. the working group expressed its intention to
  153. propose this rfc for promotion to "proposed standard."
  154.  
  155. Finally the WG suggested that a short how-to RFC be generated
  156. to describe the checklist of issues to consider in specifying
  157. an encapsulation of SNMP.  These issues are:
  158. o    Connectionless mode mapping
  159. o    Choosing addresses and sockets
  160. o    packet size
  161. o    trap pdu network address (0.0.0.0)
  162. o    transport address representation (OCTET STRING)
  163. o    "security widgets" - transport Domain OID, Default Party
  164. o    identify reliance on other "servers"
  165. o    check implementation experience
  166. Two volunteers came forward to help write this RFC.
  167. Another was identified as potentially being interested given his experience
  168. with related RFCs.
  169.  
  170.  
  171.  
  172.